Pitfalls for the page designer

• Your visitors will have a variety of screen resolutions, so you can't predict how much screen real estate you have to work with. A web page doesn't have a fixed size like paper - so any complex layout you do will probably fall over for at least some of your visitors. At low resolution, they may need to scroll sideways (a real no-no!), and at high resolution, they may see either very long lines of text, or acres of white space.



• Your visitors don't all have the same page display area inside their browsers. They may not run them full-screen; even if they do, they may have task/Office bars in different configurations; and finally they may have different buttons, toolbars and sidebars in the browser itself. So you really can't predict, even for a given resolution, what the 'paper size' will be. "The Myth of 800x600" (http://webreview.com/2001/03_16/webauthors/index01.shtml) by James Kalbach is an excellent summary of page size design considerations.



• You can't tell what fonts your visitors will have installed on their computers. Unless you use font embedding technology (which can be slow and doesn't work for everyone), you can only guess at common fonts and hope for the best. (If you decide to get around this by having all your content in graphics of your chosen font, you are creating a whole new set of accessibility problems!)



• For Windows users, you can't tell if they are using a small fonts or large fonts display setting. This can make a difference to what they see.



• Visitors will have a variety of browsers. Each browser interprets your page slightly differently, and even the simplest page will look subtly different in every browser. In the worst case, a complex page may be unusable in some browsers. You can get round this to a degree by browser detection - but this often involves using scripting (so see the next point).



• Some visitors will turn off scripting, cookies and Java applets (or have them turned off/filtered out by company policy). So, you can't rely on any effects or content that need these to work.



• If your content isn't standard web fare (in practice, this means plain text or HTML files, and JPEG or GIF images), some visitors won't have the necessary plug-ins or programs installed to see it. This applies typically to Microsoft Office documents, Adobe Acrobat files, Flash movies, and various audio, video and VRML formats.

Extreme solutions

1. Make plain vanilla pages that use the lowest common denominator. OK - everyone will see the same, but it will be pretty boring and unattractive to visitors. This may be OK for an academic archive, but probably not for most web sites.



2. Assume one resolution and screen/browser configuration, and design just for that. Tie everything down to the last pixel by using very complex tables for layout. This is what I call the DTP approach - and believe me, it just isn't effective!

The middle way

1. Read the article I suggested above, and vow not to design for 800x600 only. Come up with a design that makes the most of the web's flexibility. Think of your page as a mould into which you can pour your content - but a mould whose dimensions and aspect ratio will change for every visitor. This is my main point about not trying to do DTP on the web. Don't think in terms of grids, fixed areas and aspect ratios, but of an elastic rectangle within which you can loosely arrange your content. Kalbach describes different ways of doing this - unfortunately, all the best are "complicated to implement", as he acknowledges, and may only work in later versions of certain browsers. You should ensure, especially on your home page, that all the essential information appears without scrolling for the average visitor. On long inside pages, this may mean having a page summary and a navigation bar in the top 350 pixels, say.



2. Use CSS style sheets to control the basic colours and fonts used in your page, and the spacing of individual elements like paragraphs and lists. Read my article on using style sheets (http://lois.co.uk/web/articles/css-or-not.shtml) to find out more. As the article explains, you can design so that those visitors who can't see styles get a reasonable experience. Make sure you have a reasonable list of fonts to choose from: read my article on accessible fonts (http://lois.co.uk/web/articles/font-access.shtml) for more detail.



3. Try to follow the KISS principle (Keep It Simple, Stupid) when laying out your pages. When I first wrote this in early 2001, I didn't recommend tackling the more difficult areas of CSS styles like absolute and relative positioning, because browser support was poor. Things are very much better now, but if you are not happy to take the time necessary to get CSS layouts working, you can use simple tables to position your elements (see below for a few hints).



4. There are many resources for CSS design on the web. A good place to start is A List Apart's archive (http://www.alistapart.com/stories/) from Jeffrey Zeldman, which not only details the author's struggle to lose the design habits of a web lifetime, but also includes some useful hints on how to do it.



5. Simple rollovers (beloved of DreamWeaver authors everywhere) are fine as an enhancement to the appearance of a page. But if they contribute to the content of the site (for example revealing a text description when you roll over part of a map or diagram, or drop-down menus), some of your visitors will lose out. DHTML effects like this don't work in all browsers, and you probably need to provide down-market alternatives.



6. Don't rely on Java applets or client-side JavaScript to provide essential content for your pages, as not everyone will be able to see it. The same is true of content that requires a plug-in to view. If you must use it, think about providing a text commentary or other alternative.

• Consider the accessibility of your tables: blind people may 'see' the content sequentially, cell after cell, rather than being able to take in your carefully crafted design as a coherent whole.



• Long tables can take a while to display, unless the browser can calculate the space it needs to reserve at the outset, so it can start pouring in text immediately. A full consideration of this point is outside the scope of this article, but a good starter is to ensure that all your images in tables have height and width attributes.



• You will often (but not always) get better results by allowing the browser to calculate cell widths according to the content, than by setting pixel/percentage widths.



• If you need to specify cell widths, you may run into problems when you specify all but one cell, a mixture of pixels and percentages, or when the overall table width and the constituent cells don't add up to the same value. (I say "may", because there are no hard and fast rules - one table will work, and another almost the same won't, in the same browser.)



• Tables with complex row and/or column spans can display very poorly in Netscape 4, especially if a style sheet is associated with the page.

And finally ...